The present invention relates to computer graphics, and more particularly to rendering.
FIG. 2a illustrates typical stages in computer graphics rendering which generate a two-dimensional image on a screen from an input program that defines a virtual three-dimensional scene. In particular, the application (program) stage includes creation of scene objects in terms of primitives (e.g., small triangles that approximate the surface of a desired object together with attributes such as color and texture); the geometry stage includes manipulation of the mathematical descriptions of the primitives; and the rasterizing stage converts the three-dimensional description into a two-dimensional array of pixels for screen display.
FIG. 2b shows typical functions in the geometry stage of FIG. 2a. Model transforms position and orient models (e.g., sets of primitives such as a mesh of triangles) in model/object space to create a scene (of objects) in world space. A view transform selects a (virtual camera) viewing point and direction for the modeled scene. Model and view transforms typically are affine transformations of the mathematical descriptions of primitives (e.g., vertex coordinates and attributes) and convert world space to eye space. Lighting provides modifications of primitives to include light reflection from prescribed light sources. Projection (e.g., a perspective transform) maps from eye space to clip space for subsequent clipping to a canonical volume (normalized device coordinates). Screen mapping (viewport transform) scales to x-y coordinates for a display screen plus a z coordinate for depth (pseudo-distance) that determines which (portions of) objects are closest to the viewer and will be made visible on the screen. Rasterizing provides primitive polygon interior fill from vertex information; e.g., interpolation for pixel color, texture map, and so forth. Programmable hardware can provide very rapid geometry stage and rasterizing stage processing; whereas, the application stage usually runs on a host general purposed processor. Geometry stage hardware may have the capacity to process 16 vertices in parallel and assemble primitives for output to the rasterizing stage; and the rasterizing stage hardware may have the capacity to process 3 primitive triangles in parallel.
Image-based rendering uses two-dimensional images as primitives rather than models in three-dimensional space. Two-dimensional images avoid most of the processing of the rendering pipeline, and thus speed up processing when usable. Further, image-based rendering allows representation for difficult-to-model objects, such as clouds and fur. Image-based rendering includes varieties such as sprites, billboards, and impostors; see chapter 8 of T. Akenine-Möller and E. Haines, Real-Time Rendering (2d Ed., A K Peters, 2002). In particular, billboarding orients a polygon to face the camera/viewer and renders an image on the polygon analogous to a texture.
Sprite3D (JSR-184) is an extension of the Node class in microedition java and provides image-based rendering:
A Sprite3D object includes methods getImage( ) to get the current 2D image and getAppearnace( ) to get the current compositing and fogging attributes of the object. Sprite3D can be implemented with textured rectangles.
Various application programming interfaces (APIs) exist for implementing the rendering pipeline, such as OpenGL and DirectX, and hardware has been designed to support these APIs. For this hardware, input vertices follow a rigidly prescribed series of transformation (geometry stage) that take the vertices from object coordinates to eye space coordinates, to clip coordinates, to normalized device coordinates, and finally to screen coordinates. In order to take advantage of such hardware, applications must map their computations into a form that fits the prescribed series of transformations. In particular, the Sprite3D class of the specification JSR-184 requires vector length computations used to synthesize intermediate points in various coordinate systems, and these computations do not fit the standard rendering pipeline model. Thus there is a problem of implementing JSR-184 sprites on standard graphics hardware.